home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / lang / c++-part2 / 13782 < prev    next >
Encoding:
Internet Message Format  |  1996-08-05  |  6.4 KB
  1. Path: news.lpr.carel.fi!usenet
  2. From: Ari Lukumies <aril@cmt.lpr.mail.carel.fi>
  3. Newsgroups: alt.computer.consultants,comp.edu,comp.lang.basic.misc,comp.lang.c++,comp.lang.misc,comp.lang.pascal.borland,comp.lang.pascal.delphi.misc,comp.misc,comp.os.msdos.programmer,comp.os.os2.programmer.misc,comp.programming
  4. Subject: Re: Can we do programming without seeing the end user?
  5. Date: Wed, 27 Mar 1996 13:46:46 +0200
  6. Organization: Carelcomp Products
  7. Message-ID: <31592AA6.7B1B@cmt.lpr.mail.carel.fi>
  8. References: <BYtKnOggyTxQ071yn@oslonett.no>
  9. NNTP-Posting-Host: renoir.cclahti.carel.fi
  10. Mime-Version: 1.0
  11. Content-Type: text/plain; charset=us-ascii
  12. Content-Transfer-Encoding: 7bit
  13. X-Mailer: Mozilla 2.0 (WinNT; I)
  14.  
  15. Svein Olav Mytting wrote:
  16. > 
  17. > I sort of believe that sales and programming should be strictly
  18. > separate tasks. While a salesman should see his customer in person,
  19. > a programmer shouldn't do that.
  20. > 
  21. > My simple question is this: To which a degree can software development
  22. > be done using electronic communication as the only contact with the
  23. > sales people and/or end users?
  24. > 
  25.  
  26. Ok, here are a few things I've gathered during my nine years in 
  27. programming/designing/analysing. But first I must add that what I will say have 
  28. nothing to do with my current employer.
  29.  
  30. First, the salesmen tend to be just salesmen - they'll sell anything if they'll 
  31. make a buck. Unfortunately, many of them do not know if what they're selling can 
  32. even be implemented using the platform (OS, languages, tools, hardware) the 
  33. customer has. So, when preparing to sell something, it's a good idea to have a 
  34. discussion between the salesman and someone who knows the platform (as a 
  35. consultant). In addition, it's a good idea to have a consultant present in some 
  36. (not all of them) of the meetings between the customer and the salesman, since 
  37. the customer may come up with questions and suggestions the salesman is unable 
  38. to answer. There should also be at least one person who knows the business area 
  39. of the customer (or at least, the most important parts of it) to clarify the 
  40. extent of the deal being prepared. After the deal has been signed, the salesman 
  41. can move on to other deals, and the work of the analysts and designers begin.
  42.  
  43. To design a user interface for a program is usually best done in co-operation 
  44. with the end-user. For this purposes, a prototyping tool is ideal, especially if 
  45. it allows fast restructuring and redesigning so the user can see/test the 
  46. interface right away. What happens behind the user interface is the job of the 
  47. analyst (someone who knows the business area) and the customer's representative 
  48. to solve. Having that scetched out, the project leader can move on to break the 
  49. required processes to be programmed by the project members (programmers). 
  50. However, some parts of the system may not be fully scetched yet and may have to 
  51. overgo several iterations. This is especially true for the databases used in 
  52. large systems interacting with many different kinds of subsystems implemented 
  53. successively (eg. logic connections, management systems, laboratory systems, 
  54. orderbases etc). So, from time to time a revised version will tend to emerge. It 
  55. would be a great job, if the system was designed to allow such iteration from 
  56. the beginning, as to limit the amount of changes usually required in this kind 
  57. of production.
  58.  
  59. What's more difficult is to find limits of what should be done in the first 
  60. place, and what are improvements or enhancements that could be added later. In 
  61. one of the projects I've seen, a procedure was designed into a system, and 
  62. implementing that took about 70% of the time planned for implementing the whole 
  63. system. When the system was finished and after a year of running it, the 
  64. customer had still not found use for the new procedure and had never used it. In 
  65. addition, implementing this new procedure took so much time that some vital 
  66. parts of the system were delayed beyond acceptable limit. The problem was that 
  67. the people deciding about the importance and implementation order of the 
  68. features did not know enough of the habbits and normal work-flow of the 
  69. customer's end-users.
  70.  
  71. I've seen too many cases where the project leader did not know a) the business 
  72. area, and b) the platform and tools used either. This easily leads to a 
  73. situation where the timetables won't hold and the job is done ineffieciently. 
  74. The project leader(s) should always know their project members; what each of 
  75. them is best at (or not good at), what are their specialities etc. so s/he can 
  76. direct the different parts of the project to be done by the most suitable 
  77. person. This is called resource maintainance. Also, the project leader should 
  78. have at least some background on the platform and the business area, since it's 
  79. usually s/he who should keep in connection with the customer.
  80.  
  81. Normally, programmers would not have to deal with the customer, but in some 
  82. cases it's unavoidable. For instance, if there's some particular problem that 
  83. has to be solved and the only one specializing in that area is one of the 
  84. programmers. This case does happen every now and then, especially when dealing 
  85. with more complex systems (for example, transferring data from a previous system 
  86. built by the customer's own staff to a new one). In this case, however, the 
  87. programmer is usually considered to be a consultant or an analyst. I'd also like 
  88. to add that if a programmer spent some time getting to know the customer's 
  89. current way of doing things, he'd be better off to write the program, since he'd 
  90. come to accustomed to the way the customer might do it easier. In many cases, 
  91. it's more troublesome if the customer has to change their habbits than to extend 
  92. them.
  93.  
  94. The best organization (I've yet to see) would be one that contained three 
  95. separate groups of people. One for the people that specialize in business areas 
  96. but not much else. Another for people who specialize in platforms, hardware, 
  97. tools etc. And one for those who cannot classify in the previous two - pure 
  98. programmers (yes, there still are those). When putting up a team to produce a 
  99. system for a customer, you would take enough people from the three cathegories 
  100. and make them work together. The business-area people and the platform people 
  101. would work as kind of consultants for the project group and, as such, could also 
  102. participate in other projects same time, too, since they would not have to be 
  103. involved with one particular project whole time.
  104.  
  105. Later,
  106.  AriL
  107. -- 
  108. All my opinions are mine and mine alone and do not necessarily reflect the 
  109. opinions of my employer.
  110.